Red Hat Enterprise Linux Implementation

Network File Systems: Mounting

Module Topics

Network File System
NFS Mounting Methods
NFS Security Methods
nfs-secure
Mount an NFS Share
Automounter
Create an Automount
Direct Maps
Indirect Wildcard Maps
Connect to SMB Shares
Mount an SMB Share
Authentication to SMB Shares
Mount SMB Shares With Automounter
Mapping File

Network File System

NFS: Internet standard protocol used by Linux, UNIX, and similar operating systems as native network file system
- Open standard under active extension
- Supports native Linux permissions and file system features
Red Hat Enterprise Linux 7 supports NFSv4 by default
- If v4 not available, falls back automatically to NFSv3 and NFSv2.
NFSv4 uses TCP to communicate with server
- Older versions of NFS use either TCP or UDP

NFS Mounting Methods

NFS servers export shares (directories)
NFS clients mount exported share to local mount point (directory)
- Local mount point must exist
NFS shares can be mounted in these ways:
- Mount NFS share manually using mount
- Mount NFS share automatically at boot using /etc/fstab
- Mount NFS share on demand using automounting

NFS Security Methods

NFS server can offer single or multiple methods for each exported share
NFS clients must connect using methods mandated for that share
- To specify mount option, use sec=method

none

Anonymous access to the files, writes to the server (if allowed) are allocated UID and GID of nfsnobody.

sys

File access based on standard Linux file permissions for UID and GID values. If not specified, this is the default.

krb5

Clients must prove identity using Kerberos and then standard Linux file permissions apply.

krb5i

Adds a cryptographically strong guarantee that the data in each request has not been tampered with.

krb5p

Adds encryption to all requests between the client and the server, preventing data exposure on the network. This will have a performance impact.

Kerberos options require, as a minimum, a /etc/krb5.keytab (provided by the authentication or security administrator) and additional authentication configuration (not covered here). Request a keytab that includes either a host principal, nfs principal, or (ideally) both.

Transcript:

NFS servers secure access to files using a number of methods: none, sys, krb5, krb5i, and krb5p. The NFS server can choose to offer a single method or multiple methods for each exported share. NFS clients must connect to the exported share using one of the methods mandated for that share, specified as a mount option sec=method.

Security methods

none: anonymous access to the files, writes to the server (if allowed) will be allocated UID and GID of nfsnobody.
sys: file access based on standard Linux file permissions for UID and GID values. If not specified, this is the default.
krb5: Clients must prove identity using Kerberos and then standard Linux file permissions apply.
krb5i: adds a cryptographically strong guarantee that the data in each request has not been tampered with.
krb5p: adds encryption to all requests between the client and the server, preventing data exposure on the network. This will have a performance impact.

Kerberos options will require, as a minimum, a /etc/krb5.keytab and additional authentication configuration that is not covered in this section (joining the Kerberos Realm). The /etc/krb5.keytab will normally be provided by the authentication or security administrator. Request a keytab that includes either a host principal, nfs principal, or (ideally) both.

`nfs-secure`

Negotiates and manages communication with server when connecting to Kerberos-secured shares

Must be running to use secured NFS shares

Start and enable to ensure it is always available:

[student@desktop1 ~]$ sudo systemctl enable nfs-secure
ln -s '/usr/lib/systemd/system/nfs-secure.service'  ...
[student@desktop1 ~]$ sudo systemctl start nfs-secure

nfs-secure is part of nfs-utils package
- Usually installed by default
- To install manually, use:
  [student@desktop1 ~]$ sudo yum -y install nfs-utils

Mount an NFS Share

Identify: Do one of the following:
- Obtain export details and security requirements from NFS server admin
- Identify NFSv4 shares by mounting root folder of NFS server and exploring exported directories as root
  - Denies access to shares using Kerberos security
  - Share (directory) name is visible
  - Other share directories are browsable
    [student@desktop1 ~]$ sudo mkdir /mountpoint [student@desktop1 ~]$ sudo mount server1:/ /mountpoint [student@desktop1 ~]$ sudo ls /mountpoint
- Discover NFSv2 and NFSv3 shares using showmount
  [student@desktop1 ~]$ showmount -e server1
Mount point: Use mkdir to create mount point in suitable location:
```
[student@desktop1 ~]$ mkdir -p /mountpoint
```

Mount an NFS Share

Mount: Switch to root or use sudo and do one of the following:
- Manual: Use mount
  - To specify file system type for NFS shares, use -t nfs (not strictly required)
  - To synchronize write operations with NFS server, use -o sync (default is asynchronous)
    [student@desktop1 ~]$ sudo mount -t nfs -o sync server1:/share /mountpoint
- /etc/fstab: Use vim to add mount entry to bottom of /etc/fstab
  - NFS share is mounted at each system boot
    [student@desktop1 ~]$ sudo vim /etc/fstab ... server1:/share /mountpoint nfs sync 0 0
- To manually unmount the share, use umount with root privileges
  [student@desktop1 ~]$ sudo umount /mountpoint

References

Man pages: mount(8), umount(8), fstab(5), and mount.nfs(8)

Automounter

autofs service managed like other system services
Can automatically mount NFS shares on demand
Automatically unmounts NFS shares when no longer used
Do not need root privileges to run mount or umount
- NFS shares available to all users with access permissions
Frees network and system resources
- Unlike entries in /etc/fstab, NFS shares are not permanently connected
No server-side configuration
Uses same mount options as mount
Flexible mount point locations
- Direct and indirect mount point mapping
No need to manually manage indirect mount points
- Created and removed by autofs
Can automount range of file systems (default=NFS)

Transcript:

The automounter is a service (autofs) that can automatically mount NFS shares "on demand," and will automatically unmount NFS shares when they are no longer being used.

Automounter benefits

Users do not need to have root privileges to run the mount/umount commands.
NFS shares configured in the automounter are available to all users on the machine, subject to access permissions.
NFS shares are not permanently connected like entries in /etc/fstab, freeing network and system resources.
The automounter is configured entirely on the client side; no server-side configuration required.
The automounter uses the same mount options used by the mount command, including security options.
Support for both direct and indirect mount point mapping, providing flexibility in mount point locations.
Indirect mount points are created and removed by autofs, alleviating the need to manually manage them.
NFS is the default file system for the automounter, but it can be used to automount a range of different file systems.
autofs is a service that is managed like other system services.

Create an Automount

Install autofs:

[student@desktop1 ~]$ sudo yum -y install autofs

Add master-map file to /etc/auto.master.d:
- Identifies base directory for mount points
- Identifies mapping file for creating automounts
  1. Use vim to create and edit master-map file:
    [student@desktop1 ~]$ sudo vim /etc/auto.master.d/demo.autofs
    
    Must have .autofs extension
    Can hold multiple mapping entries
    Or, use multiple files to separate configuration data
  2. Add master-map entry to same or separate file:
    For indirectly mapped mount points, add /shares /etc/auto.demo
    All indirect map entries use /shares as base directory
    /etc/auto.demo contains mount details
    Create auto.demo before starting autofs
    For directly mapped mount points, add /- /etc/auto.direct
    All direct map entries use /- as base directory
    /etc/auto.direct contains mount details

Transcript:

Configuring an automount is a multistep process:

Install the autofs package using: sudo yum -y install autofs
This package contains everything needed to use the automounter for NFS shares.
Add a master-map file to /etc/auto.master.d. This file identifies the base directory used for mount points and identifies the mapping file used for creating the automounts.
Use vim to create and edit the master-map file: sudo vim /etc/auto.master.d/demo.autofs

The name of the master-map file is not important, but it is normally something meaningful. The only requirement is it must have an extension of .autofs. The master-map file can hold multiple mapping entries, or use multiple files to separate configuration data.

Add the master-map entry, in this case, for indirectly mapped mounts: /shares /etc/auto.demo

This entry would use the /shares directory as the base of future indirect automounts. The /etc/auto.demo file contains the mount details; use an absolute filename. The auto.demo file needs to be created before starting the autofs service.

To use directly mapped mount points, add an entry to the same file (or in a separate file): /- /etc/auto.direct

All direct map entries use /- as the base directory. In this case, the mapping file that contains the mount details is /etc/auto.direct.

Create an Automount

Create the mapping file(s) to identify mount point, mount options, and source location:
1. Use vim to create and edit mapping file:
  [student@desktop1 ~]$ sudo vim /etc/auto.demo
  - Located in /etc and called auto.name (replace name with something meaningful)
2. Add map entry:
  work -rw,sync server1:/shares/work
  - Entry format: mount point, mount options, source location
    Mount point or key: Created and removed automatically by autofs
    No need to align local mount point names and server directory structure
    Mount options: Start with - (dash) and are comma-separated with no white space
    Options available are same as manual mount
    Useful automount-specific options:
    Use fstype to specify the file system if it is not NFS
    Use strict to treat errors, when mounting file systems, as fatal
    Source location: NFS shares follow host:/pathname pattern
    If file system to be mounted begins with / (slash), such as local device entries or SMB shares, then prefix with : (colon)
    Example: SMB share would be ://server1/share.

Transcript:

Create the mapping file(s). The mapping file identifies the mount point, mount options, and source location to mount.
Use vim to create and edit the mapping file.

The file name is not important, but by convention is located in /etc and called auto.name, where name is something meaningful to the included contents.

The format of an entry is mount point, mount options, and source location. This example is showing a basic indirect mapping entry. Direct maps and indirect maps using wildcards will be covered later in this section.
- Known as the "key" in the man pages, the mount point will be created and removed automatically by the autofs service. In this case, the fully qualified mount point will be /shares/work—see the master-map file. The /shares directory and the work directory will be created and removed as needed by the autofs service.
  In this example, the local mount point mirrors the server’s directory structure. The local mount point can be named anything. There is no requirement to align the names of the local mount point and the server directory structure.
- Mount options start with a "-" (dash) and are comma-separated with no white space. The mount options available are the same as those available to the equivalent manual mount command. In this example, the automounter will try and mount the share using read/write access, security will be based on standard Linux file permissions (the default: sec=sys), and the server will be synchronized immediately during write operations.
  There are a couple of useful automounter specific options: -fstype= and -strict. Use fstype to specify the file system if it is not NFS and use strict to treat errors, when mounting file systems, as fatal.
- The source location for NFS shares follows the host:/pathname pattern; in this example, server1:/shares/work. This directory will need to have been exported on server1 with support for read/write access and standard Linux file permissions for the mount to be successful. If the file system to be mounted begins with a "/" (slash), such as local device entries or SMB shares, then a ":" (colon) needs to be prefixed; for example, an SMB share would be ://server1/share.

Create an Automount

Use systemctl to start and enable autofs:

[student@desktop1 ~]$ sudo systemctl enable autofs
ln -s '/usr/lib/systemd/system/autofs.service'  ...
[student@desktop1 ~]$ sudo systemctl start autofs

Direct Maps

Map NFS share to existing mount point
Automounter will not attempt to create mount point automatically
- Example: content for /etc/auto.direct might look like:
  /mnt/docs -rw,sync server1:/shares/docs
Mount point (or key) is always an absolute path
- Starts with / (slash)
- Rest of mapping file uses same structure
Only right-most directory under automounter control
- Directory structure above mount point is not obscured by autofs

Indirect Wildcard Maps

Automounter can be configured to access any subdirectory exported by NFS server using single mapping entry
- Example, if server1:/shares exports two or more subdirectories that are accessible with same mount options, then content for /etc/auto.demo might look like:
  * -rw,sync server1:/shares/&
- Mount point (or key) is * (asterisk)
- Subdirectory on source location is & (ampersand)
- Everything else in entry is same as direct entry

References

Man pages: autofs(5), automount(8), auto.master(5), and mount.nfs(8)

Transcript:

When an NFS server is exporting multiple subdirectories within a directory, then the automounter can be configured to access any one of those subdirectories using a single mapping entry. As an example, this can be really useful for automounting user home directories from an NFS server.

Continuing the previous example, if server1:/shares is exporting two or more subdirectories and they are able to be accessed using the same mount options, then the content for the /etc/auto.demo file might look like below.

The mount point (or key) is an "*" (asterisk), and the subdirectory on the source location is an "&" (ampersand). Everything else in the entry is the same.

When a user attempts to access /shares/work, the key * (which is work in this example) will replace the ampersand in the source location and server1:/shares/work will be mounted. As with the indirect example, the work directory will be created and removed automatically by the autofs service.

Connect to SMB Shares

Red Hat Enterprise Linux uses Samba server to provide services Microsoft Windows clients can use
Samba implements SMB protocol
- CIFS is dialect of SMB
Red Hat desktops and servers can connect to shares offered via any server that uses SMB protocol
1. Identify remote share to access
2. Determine mount point where share should be mounted and create mount point’s empty directory
3. Mount network file system with appropriate command or configuration change
Before mounting SMB shares:
- Install cifs-utils (required)
- Install samba-client (optional)

Transcript:

Many organizations need to provide network storage and print services for a range of desktop operating systems. Red Hat Enterprise Linux uses the Samba server to provide services that Microsoft Windows clients can use. Samba implements the Server Message Block (SMB) protocol, and Common Internet File System (CIFS) is a dialect of SMB. Often the two names are used interchangeably.

Red Hat desktops and servers can connect to shares offered via any server that use the SMB protocol.

Three Basic Steps for Accessing an SMB Share

Identify the remote share to access.
Determine a mount point where the share should be mounted and create the mount point’s empty directory.
Mount the network file system with an appropriate command or configuration change. Before starting, there is one package that must be installed in order to mount SMB shares: cifs-utils. Both the mount command and autofs automounter rely on this package for mounting CIFS file systems.

A second package, samba-client, has some useful command-line utilities—for example, smbclient—and is often worth installing as well.

Mount an SMB Share

Identify: Do one of the following:
- Obtain share details from SMB server host admin
- Use client that can browse shares, such as smbclient
  [student@desktop1 ~]$ smbclient -L //server1
  - Use -L to list available shares
Mount point: Use mkdir to create mount point in suitable location:
```
[student@desktop1 ~]$ mkdir -p /mountpoint
```

Mount an SMB Share

Mount: Switch to root or use sudo and do one of the following:
- Manual: Use mount
  - To specify SMB as file system type, use -t cifs
  - To try and authenticate as guest account without password, use -o guest
    [student@desktop1 ~]$ sudo mount -t cifs -o guest //server1/share /mountpoint
- /etc/fstab: Use vim to add mount entry to bottom of /etc/fstab
  [student@desktop1 ~]$ sudo vim /etc/fstab ... //server1/share /mountpoint cifs guest 0 0
- To manually unmount the share, use umount with root privileges
  [student@desktop1 ~]$ sudo umount /mountpoint

Authentication to SMB Shares

Can flag SMB shares as non-browsable
- Clients such as smbclient will not display them
- Can still access shares by explicitly specifying share name during mount
SMB servers typically restrict access to specific users, or groups of users
- Must present credentials to SMB server to access protected shares
- SMB server can use a wide range of authentication methods
- Common authentication choice is username and password pairs
  - Can either be added to mount or /etc/fstab entry
  - Can be stored in credentials file referenced during mount
- mount prompts for password if not provided
- Password must be provided if using /etc/fstab
- To explicitly request guest access, use guest

Transcript:

Authentication to SMB shares SMB shares can be flagged as non-browsable, meaning clients such as smbclient will not display them. The SMB shares are still accessible by explicitly specifying the SMB share name during the mount operation.

SMB servers typically restrict access to specific users, or groups of users. Accessing protected shares will require appropriate credentials be presented to the SMB server. There are a range of authentication methods that an SMB server can choose to implement, too many to cover here.

A common choice for authentication is username and password pairs. These can either be added to the mount command (or /etc/fstab entry) or stored in a credentials file that is referenced during the mount operation. The mount command will prompt for a password if it is not provided, but it must be provided if using /etc/fstab. Guest access can be explicitly requested with the guest option.

Authentication to SMB Shares

Example: Mount SMB share //server1/docs at /public/docs and attempt to authenticate as guest without password prompt
```
[student@desktop1 ~]$ sudo mount -t cifs -o guest //server1/docs /public/docs
```
Example: Mount SMB share //server1/cases at /bakerst/cases and attempt to authenticate as watson with password prompt
```
[student@desktop1 ~]$ sudo mount -t cifs -o username=watson //server1/cases /bakerst/cases
```
credentials offers better security
- Stores password in more secure file than /etc/fstab which is easily examined
- Place credentials somewhere with only root access, such as chmod 600
  - Example: Mount SMB share //server1/sherlock at home/sherlock/work and attempt to authenticate using credentials stored in /secure/sherlock
    [student@desktop1 ~]$ sudo mount -t cifs -o credentials=/secure/sherlock //server1/sherlock /home/sherlock/work

Credentials file format:

username=username
password=password
domain=domain

Transcript:

Some examples:

Mount the SMB share //server1/docs at /public/docs and attempt to authenticate as guest.

Mount the SMB share //server1/cases at /bakerst/cases and attempt to authenticate as watson. The mount command will prompt for the password in this example.

The credentials file offers better security because the password is stored in a more secure file, whereas the /etc/fstab file is easily examined.

Mount the SMB share //server1/sherlock at /home/sherlock/work and attempt to authenticate using the credentials stored in /secure/sherlock.

The format for the credentials file is: username=username password=password domain=domain

It should be placed somewhere secure with only root access (for example, chmod 600).

During file operations, the SMB server will check file access against the credentials used to mount the share. The client will check file access against the UID/GID of the files sent from the server. This means that the client will need to have the same UID/GID, and if necessary, supplementary group membership as the files on the SMB server.

There are a number of mount options that handle local access checking and alternate authentication methods, such as multiuser (and cifscreds) and Kerberos-based options. They will not be covered here; for more information, refer to the man pages and articles available at access.redhat.com.

Mount SMB Shares With Automounter

Can configure automounter (autofs) to mount SMB shares on demand
- When process attempts to access file on SMB share
Automounter unmounts share after certain period of inactivity
Process to set up autofs on SMB share is essentially same as other automounts:
1. If not already installed, install autofs
2. Add auto.master.d configuration file
  - Identifies base directory for shares and mapping file
3. Create or edit mapping file to include mount details for SMB share
4. Enable and start autofs

Automounter depends on cifs-utils for mounting SMB shares

Transcript:

Mounting SMB file systems with the automounter

Using the mount command requires root privileges to connect to the SMB shares. Alternatively, entries can be added to /etc/fstab, but then the connections to the SMB servers would be active all the time.

The automounter, or autofs, service can be configured to mount SMB shares "on demand" when a process attempts to access a file on the SMB share. The automounter will then unmount the share once it is no longer in use, after a certain period of inactivity.

The process for setting up an automount on a SMB share using autofs is essentially the same as other automounts:

Add an auto.master.d configuration file that identifies the base directory for shares and the associated mapping file.
Create or edit the mapping file to include the mount details for the SMB share.
Enable and start the autofs service.

If it is not already installed, install the autofs package. Like mount, the automounter is also dependent on the cifs-utils package for mounting SMB shares.

Mapping File

To specify file system type, use -fstype=cifs followed by comma-separated list of mount options
- Use same options as mount
- Prefix server URI address with a : (colon)
Example: Create an automount at /bakerst/cases for SMB share //server1/cases, and authenticate it against the /secure/sherlock credentials file
- /etc/auto.master.d/bakerst.autofs content:
  /bakerst /etc/auto.bakerst
- /etc/auto.bakerst content:
  cases -fstype=cifs,credentials=/secure/sherlock ://server1/cases
- /secure/sherlock content (owned by root, perms 600):
  username=sherlock password=violin221B domain=BAKERST

autofs enable and start:

[student@desktop1 ~]$ sudo systemctl enable autofs
[student@desktop1 ~]$ sudo systemctl start autofs

References

Man pages: mount(8), umount(8), fstab(5), mount.cifs(8), smbclient(1), autofs(5), automount(8), and auto.master(5)

Summary

Network File System
NFS Mounting Methods
NFS Security Methods
nfs-secure
Mount an NFS Share
Automounter
Create an Automount
Direct Maps
Indirect Wildcard Maps
Connect to SMB Shares
Mount an SMB Share
Authentication to SMB Shares
Mount SMB Shares With Automounter
Mapping File

Module Completion

Nice job!

Click the button below to complete this module of the course: